Skip to main content

CAD Programming

· 3 min read
Rainer Weigel
Rainer Weigel
AWV Co-Founder

The landscape of programmable CAD is evolving rapidly. From browser-based platforms to headless geometry engines, developers now have a range of tools to express and automate CAD logic through code. This article explores two fundamental philosophies shaping this evolution:

Two Philosophies in CAD Programming​

This is our slogan:

**Code is CAD's native language for machines. **

Because only code is truly machine-producible, editable, and generative-ready.

1. Code-as-Geometry Languages
like CadQuery, OpenSCAD, and Zoo.dev
2. Feature-based Procedural APIs
like Onshape’s API, SolidWorks API, ClassCAD API and similar tools

Philosophy 1: Code-as-Geometry (Declarative Modeling)​

This category treats a model as a function of code — define a shape, set parameters, and output solid geometry.

  • Stateless: Each model is defined fresh on each execution.
  • Functional-style: Inputs → outputs, no persistent model context.
  • Parametric-friendly: Ideal for configuration and generative use cases.
  • No runtime mutation: You cannot "go back" to edit a prior step.

This builds the model in one shot — with no persistent editable model tree.

Philosophy 2: Feature-by-Feature APIs (Procedural Modeling)​

These environments treat the model as a mutable object that evolves over time, much like a traditional CAD user works with sketches and features

  • Stateful: The model exists in memory and evolves incrementally.
  • Feature-tree driven: Each step adds to or modifies the model.
  • Supports custom tools: You can define new features or UI interactions.
  • Ideal for automation and custom CAD logic.

Each step mutates the model, and you can change, reorder, or inspect features dynamically.

Our approach: We take the best from both worlds​

One of our main goal is to bring designers and programmers closer together. We focus thus on the parametric features, as described in Philosophie 2, because features are their common language and both understand how to handle them. Every feature creation API function has its counterpart as a GUI plugin in our interactive Buerligons system.

But to bridge the gap between the two philosophies, we provide a special feature, called entity injection. This feature basiclly correspond a custom feature script, the programmer develops and the designer can also execute. This feature acts like a container to hold curves and solids, which can destructivly be modified. Solid API provides Code-as-Geoemetry functionality and features like extrusions, booleans, slice etc operates directly on the solids WITHOUT creating full fledge feature objects. Visit our examples repos on GitHub [link] and see the lego configurator creating parametric objects without without history.

Conclusion​

Whether you're building parametric product configurators or custom CAD tools, understanding these two philosophies helps you choose (or design) the right toolchain. Declarative geometry languages make for clear and reproducible code, while procedural APIs offer granular control and extensibility. Each has its strengths — and together, they shape the next generation of programmable design. By combing both we allow our useres to choose the best for their custom CAD!